The subject matter discussed in the background section should not be assumed to be prior art merely as a result of its mention in the background section. Similarly, a problem mentioned in the background section or associated with the subject matter of the background section should not be assumed to have been previously recognized in the prior art. The subject matter in the background section merely represents different approaches, which in and of themselves may also correspond to embodiments of the claimed inventions.
A single a multi-tenant database system operates to store data on behalf of a multitude of paying subscribers, each being a “tenant” of the database system, hence the term multi-tenant database system.
Within such an operational environment, computational efficiency, system responsiveness, and data integrity are all of paramount concern both to the provider of the multi-tenant database system and to the subscribers or tenants of such a system. Moreover, with on-demand technologies having multiple distinct clients simultaneously utilizing the system and relying upon its availability it is critical to avoid service outages which can create frustration on behalf of users, create bad press coverage for the host organization, and damage the credibility of the host organization which in turn creates a negative business environment making it more difficult to acquire new customers and retain existing customers.
Within conventional database systems, data corruption detected by the database engine software is considered a catastrophic event, as it should be, causing the database to very often “crash” rather than risk serving corrupted data in reply to queries. Some enterprise level databases do not crash and perform special isolation techniques instead. Nevertheless, a crashed database may be acceptable in a single tenant environment where one entity hosts their data on the database and is responsible for maintaining their own database internal to an organization because a catastrophic failure and database crash will result in only that particular tenant's users being affected.
However, consider the environment in which a multi-tenant database system operates as an on-demand or cloud based subscription service providing database services to tens of thousands of customers. A catastrophic failure in such an environment due to data corruption will affect a large number of customer organizations, their business operations, their users, customers of those businesses, and so forth. Even if a catastrophic failure is limited within a multi-tenant database system to a single server pod or some logical subset, the failure will still affect hundreds or thousands of customers having data on such a sub-set rather than only a single entity as would occur in a single-tenant database system. In addition to the bad press and loss of credibility, such a database crash can directly lead to millions of dollars per hour of lost revenue for the duration of the outage. Further still, a single tenant of a multi-tenant database system cannot be permitted to trigger a database outage that could affect potentially thousands of other tenants of the same multi-tenant database system, each of whom are running their own businesses. It would be grossly unfair for a single tenant to detrimentally impact so many others in such a way.
Rectifying database corruption is additionally notoriously difficult and requires skilled database experts and technicians, which in turn leads to further cost and delay in the recovery of database services. At the same time, corruption in a database is a critical problem and cannot simply be ignored as returning corrupted data in reply to queries could have even more damaging results than returning no data at all due to a service outage.
The present state of the art may therefore benefit from the systems, methods, and apparatuses for fixing logical or physical corruption in databases using immutable LSM trees as described herein.